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Title : Rekeying in Secure l\Aoblle Multicast Communications 

Description 

Field of the invention 

5 This invention relates to rekeying in secure mobile multicast communications 

and, more specifically to Inter-area rekeying of encryption keys. 

Background of the invention 

The emergence of new Internet applications such as video-conferencing, 
e-leaming and many other applications which are based on group communications 

10 experience new challenges such as support of user mobility* A new type of 
Internet solution is being specified to allow users to communicate with multiple 
remote hosts while moving in the Internet. In the perspective of deploying 
multiparty-based applications, the Internet Engineering Task Force (IETF) has 
defined the IP multicast model [S. Deering, "Host Extension for IP Multicasting", 

15 Internet RFC 1112, August 19891, This model allows any user to send Data Traffic 
In a single copy of its message to a group of hosts knowing only their group 
address, or more exactly their multicast address: members join the group by 
subscription without the sender needing (nor being able) to use the individual 
group members' unlcast addresses. The sender's message is then optimally 

20 duplicated by multicast routers on the path towards the receivers. 

Unfortunately, the IP Multicast model was originally specified without security 
support. This issue remains an obstacle for a broader deployment of IP multicast, 
especially for security-sensitive applications such as Pay-Per-View, private 
conferences and military communications, for example, where data confidentiality 

25 in a dynamic membership context is necessary. Furthermore, tiie mobility of users 
complicates the IP multicast security problem. 

While general aspects of the multicast security issues [for example T. 
Hordjono and B. Weis. " The Multicast security (MSEC) Architecture", Internet 
draft, draft-ietf-msec-arch-04.bct, November 2003] and group encryption key 
30 management issues [for example Mark Baugher and aL, The Group Domain of 
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Interpretation". Internet RFC 3574, July 2003] have been broadly addressed 
through multiple works and studies, the Impact of member's mobility has not been 
widely considered. The expression 'Intra-group mobility" Is used herein to refer to 
movement of member between administrative areas ('Inter-autonomous-system 
5 mobility'), without leaving or joining a group. The group Is nomially defined by the 
multicast address to which the member has subscribed. However, in some 
circumstances, it would be desirable for a mobile member to remain part of a 
group defined by the Traffic Encryption Key while changing multicast address. 

Such mobility complicates the IP multicast security problem. In fact, inter- 
10 autonomous-systemmobillty confuses the group membership dynamism since 
mobile members not only wish to join or leave the multicast group, but may also 
wish to move within the group between networks or areas while remaining (from a 
group membership viewpoint) In the secure session. However, member's 
movement between networks or areas may compromise data secrecy. This would 
15 nonnally require expensive rekeying (the generation of new keying materials) for 
the existing members In order to ensure data secrecy (Fonward and Backward 
Secrecies). Such a constraint Is due to the fact that the underlying group key 
management service was only designed for stationary members [M. Baugher, R. 
Canetti. L. Donetl. and F. Lindholm. "Group Key Management Architecture", 
20 Intemet draft, draft-letf-msec-gkmarch-06.bct. September 2003]. 

The Multicast Security (msec) Working Group of the Intemet Engineering 
Task Force (IETF) specifies a common architecture for secure multicast 
communications [T. Hordjono and B. Wels. "The Multicast security (MSEC) 
Architecture", Internet draft. draft-letf-msec-arch-04.b(t. November 2003]. This 
26 architecture defines a security entity used for delivery and management of 
cryptographic keys In secure groups. Such an entity is called the Group Controller 
Key Server (GCKS). The algorithms that manage the distribution, rekeying 
('updating'), and revocation of the group keys are known as group key 
management protocols. The challenge of any key management protocol is to 
30 generate and distribute new keys such that the data remains secure while the 
overall Impact on system performance Is minimized. There are two basic designs 
of group key management model: a centralized design and a distributed design. 
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In the centralized design, there is a single GCKS that manages the keying 
material for all the group membere. . 

In a distributed architecture the GCKS entity interacts securely with other 
GCKS entities to provide more scalable group management services, and hence 
to avoid signaling overtiead and system bottleneck in the case of a large number 
of group members, which are more likely in the case of a centralized architecture. 
The manager of the entire group - the domain - is called the Domain GCKS. The 
domain Is divided Into administrative regions called areas. The area may be 
constructed on either a physical or a logical basis. For example, an area may 
represent a Corporate Networtc, or may contain a set of users that belong to a 
common logical group or coalition, independently of their physical location. Each 
area Is managed by an area GCKS. a 'local GCKS'. The present invention relates 
to the distributed architecture. 

In order to ensure the confidentiality of multicast application data, the Domain 
GCKS generates and distributes to all group members a common key called a 
Traffic Encryption Key (TEK). This key Is used by the multicast source to encrypt 
data traffic, and by receivers to decrypt source's data. In a distributed scheme, 
when the Domain GCKS generates the data key (TEK). it multicasts it securely to 
each area's local Group Controller Key Server (GCKS). The local GCKS is 
responsible for distributing the TEK to members within its area in a secure fashion 
using a specific key called: Key Encryption Key (KEK). These keys are used by 
the local GCKS to encrypt the TEK and subsequent KEK versions (local rekeying). 
The means by which the tocal GCKS distributes keys in a secure fashion may 
Include a unlcast or multicast secure channel, a logical hierarchy of keys or an 
extension of the server hierarchy. This firameworit is depicted in Figure 1 of the 
accompanying drawings. 

The group is dynamic, so that when a new member joins the group, the TEK 
must be changed to ensure that the newly joining member cannot decrypt previous 
communications; this requirement is called Backward Secrecy. In the same way, 
whenever a member leaves the group session, the TEK must be changed - 
rekeyed - to ensure that the leaving member cannot decrypt further 
communications using the TEK it held, before leaving the session; such a 
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requirement is called Forward Secrecy. In addition, during a secure multicast 
session, keys will have a predetermined lifetime and will be periodically refreshed 
according to particular intervals. This ensures that no keying material remains 
valid for more than a fixed period of time. 
5 In more detail, when a new member joins the group through a given area it 

sends the local GCKS a signalling message to request the Group Traffic 
Encryption Key (TEK) as well as the local KEK. The local GCKS then creates and 
multlcasts a new KEK to all the existing members of its area encrypted with the 
previous KEK. The new KEK is also unicast to the new member using a secure 
10 channel established using suitable mechanisms such as those based on a shared 
key or member's public key. Once the new KEK is distn-buted in the relevant area, 
the Domain GCKS multicgsts the new TEK to all local GCKSs and then each local 
GCKS (GCKSi. GCKSj and so on) forwards the new TEK to group members in 
their respective areas In one multicast distribution using the respective KEKs 
15 (KEKi. KEKj and so on). The process of updating the keying material when a new 
member joins the group ensures backward secrecy. As a result, the new member 
cannot have access to an unchanged KEK to decrypt the previous TEK that was 
encrypted with an unchanged KEK. and thus cannot obtain data transmitted prior 
to its arrival. 

20 When a member leaves the multicast group, all the valid keys it held just 

before leaving the session must be changed by notifying its local GCKS. in this 
case, the member's local GCKS will create and distribute a new KEK to the 
remaining area members. The proposed solutions for inter-area rekeying we will 
review here suggest using a unicast secure channel to distribute the new KEK to 

25 each remaining member, instead of multicasting, since for both scalability and 
perfomiance reasons, the GCKS does not have an encryption key shared only 
with all the remaining members (that is to say all except the leaving member), and 
hence the GCKS could not use multicast to send the new KEK only to the 
remaining members. Once the new KEK is distributed, the Domain GCKS 

30 generates and distributes a new TEK to all the local GCKSs. Each local GCKS 
then fonwards securely the new TEK to all its area members using the KEK. This 
method ensures fonward secrecy. That is. a leaving member cannot decrypt future 
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group communications in any area because it does not have the required keying 
materials (I.e. the new TEK and the new KEK). - 

In summary, the group key management service is required to ensure the 
following features in respect of all group members, even for group members that 
move intra-group between different areas in the domain - inter-area mobility : 

• Confidentiality: Only group members can read the multicast traffic. 

• Backward secrecy: Every time a new member joins the group, the Traffic 
Encryption Key (TEK) must be changed for all group members to ensure 
that the new member cannot decrypt previously transmitted data traffic. 

• Forward secrecy: When any group member leaves the multicast group, the 
TEK must be changed for the remaining group members to ensure that the 
leaving member cannot decrypt subsequent data traffic. 

The situation for intra-group inter-area mobility is illustrated in Figure 2, in 
which a current group member MMij initially in the area managed by GCKSi moves 
intra-group to the area managed by GCKSj, a current group member MMji initially 
in the area managed by GCKSj moves intra-group to the area managed by GCKSj, 
and a current group member MMxj initially in the area managed by GCKSk moves 
intra-group to the area managed by GCKSj. 

It will be appreciated that each area may contain one or more Autonomous 
Systems (ASs) such as Corporate Networks that may represent a distinct 
organization witti its own physical network. The ASs may also be limited by 
geographical constraints. Problems have arisen with proposed mechanisms for 
rekeying, due to security policies, key latency and risks of traffic interruptions and 
over-frequent inter-area signalling. 

One known proposal, referred to as a Static Rekey (SR) approach is 
Illustrated in Figure 3 [C. Zhang and al., "Comparison of Inter-Area Rekeying 
Algorithms iFor Secure Wireless Group Communications". IFIP WG 7.3 
International Symposium on Computer Performance Modeling. Measurement and 
Evaluation, September 2000]. In this proposal, the local GCKSj maintains the KEKi 
unchanged when a mobile member MMg moves intra-group to a new area. That is. 
the mobile member MMg will continue receiving the KEKi originating from its 
GCKSi. To achieve this, the GCKSi may use inter-area multicast to distribute 
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updates of KEKi for members out of the area. Otherwise, it may use a forwarding 
node, such as the Home Agent in the case of Mobile IP. 

This approach Is straightfonward and does not require the mobile member 
MMi) to register with the new local GCKSj whenever it moves to a new areaj. In 
addition, movement of the member MMij between the two areas affects neither the 
members of the previous area nor those of the new one. However, the Static 
Rekey approach may not work in case where the mobile member moves to a 
network that belongs to a new administrative area where the security policy 
restricts the traffic and the interactions with foreign areas. This may be the case 
when the entire networic consists of a coalition composed of loosely connected 
ASs (e.g.. In cooperative military), for example, or when the keys are multicast to 
the members. Moreover, with the Static Rekey Approach the distribution of keying 
material to members MM( out of their areas may suffer latencies or may even fail. 
Such problems are especially constraining in applications that depend on a rapid 
dissemination of secure information such as military operations, for example. 

In order to reduce both these latencies and inter-AS Signaling, new 
approaches have been defined proposing mapping the logical area structure 
directly onto the physical topology of the networic. In addition, these approaches 
propose moving the key changes as close as possible to the members, shifting 
existing trust relationships to the current location of the mobile member to support 
future key exchange and eliminating the member's dependence on a distant 
security server. 

If the inter-area movement of the mobile member MMij were simply 
considered as a leave from the old area GCKSi followed by a join to the new area 
GCKSj. this case would be assimilated to that of a member joining and/or leaving 
the group altogether. This would introduce an internjptlon of data transmission as 
well as additional computations whenever the mobile member transfers between 
areas. In addition, new TEKs may be generated twice due to the movement of the 
member MM^ If the Domain GCKS considers that the entering member is both a 
member leaving and a member joining the group. 

Another known proposal, referred to as an Immediate Rekey (IR) approach Is 
illustrated in Figure 4 [B. DeCleene, L.Dondetl. S. Griffin, T. Hardjono, D. Kiwior, J. 
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Kurose, D. Towsley. S. Vasudevan, and C. Zhang. "Secure Group 
Communications for Wireless Networks", Proceedings of Military Communications 
Conference, IEEE MILCOM, Communications for Network-Centric Operations: 
Creating the Information Force. Vienna, October 2001, pp. 113-117]. The 
5 Immediate Rekey algorithm defines new semantics that address member's 
mobility. In fact, when a group member MMg moves to a new area, it sends a 
signaling message to the previous GCKSi as well as the visited GCKSj. The areas 
GCKSi and GCKSj then update their local KEKs. No TEK rekey is required since 
the member MMg proves its group membership to the new local GCKSj using 
10 specific Information called credentials, for example In the manner described in S. 
Griffin, B; DeCleene, L. Dondeti, R. Flynn, D. Kiwior. and A. Olbert." Hierarchical 
Key Management for Mobile Multicast Members. Accordingly, the data 
transmission continues uninterrupted. 

This approach is simple from a key management point of view. In addition, it 
15 separates the case of Intra-group mobile members from that of members entering 
or leaving the group by maintaining the TEK unchanged when a cunrent group 
member moves between areas. However, it implies systematic rekeying of the 
local KEKs KEK{ and KEI^ for ail group members within the areas affected by the 
handover of the mobile member MMy. Thus, the efficiency of this approach is 
20 seriously affected in the case of group members with a high inter-area mobility. 

Yet another known proposal, referred to as a First Entry Delayed Rekey+ 
Periodic (FEDRP) approach is illustrated in Figure 5 [C. Zhang and al., 
"Comparison of Inter-Area Rekeying Algorithms for Secure Wireless Group 
Communications", IFIP WG 7.3 International Symposium on Computer 

25 Performance Modeling, Measurement and Evaluation, September 2000]. The 
FEDRP approach is like the IR approach in the use of semantics of transfer 
between areas, it enhances this approach, however, since no local rekeying 
occurs in the previous area. That is, when the member MMy moves intra-group 
from areai to areaj, it sends one signalling message to GCKSi and one signalling 

30 message to GCKSj. GCKSi then adds the member MM^ to a list of members that 
have left the area by intra-group mobility without leaving the group and still hold a 
valid area key KEKi for a limited period of time. This list is called an Extra Key 



CMU>12a3EP-ePC SpoeVnn^ 



IBDaeemberim 



10 



15 



20 



25 



Owner List (EKOL). It Is reset when and if a member holding a valid area key 
KEK. in area, or visiting another area, leaves the group and when the timer of the 
validity period expires. In some cases, the mobile member MM« may accumulate 
multiple KEKs that correspond to different areas it has been in. If the mobile 
member MM, returns to an area it has previously visited, the local GCKS checks .f 
this member is on the local EKOL list. If this is the case, it will be removed from the 
list and no rekeying will be needed. In this case, the mobile member MM« receives 
(optionally) the current KEK, using a secure channel. However. If the member MM, 
is not present in the list, a new KEK. is generated and sent in one multicast 
distribution to current area members using the previous KEK,. and in a unicast 
transmission using a secure channel to the mobile member MMg. 

In order to ensure fonwaid secrecy, when a mobile member MM,, visiting 
another area leaves the group session, all the KEKs It holds must be changed for 
all the group members holding those KEKs within the affected areas and. in 
addition, all the EKOL lists holding those KEKs are reset The KEK, that the 
member holds out of area, may also be changed under specific conditions related 
to EKOL, (especially expiration of the key validity period). 

The FEDRP approach Improves significantly the inter-area rekeying by 
keeping the KEK, of the previous area GCKS, unchanged. However, the FEDRP 
approach suffers from systematic rekeying when the mobile member enters ^ new- 
area GCKS, for the first time. That is. when the member MM, moves to the new 
area GCKS,, its mobility is supported in the previous area GCKS,. but not In the 
visited area GCKS,. In addition, during the session duration, it is more probable 
that a member enters a given area for the first time than for more than one time. 
As a result, when a member moves between areas, it is highly probable that a 
local rekeying occurs in the visited area. 

It is desirable to provide a lightweight mechanism that optimizes the 
computation for mobile members while reducing the impact of their movement on 
group rekeying 
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Summary of the invention 

The present invention provides a method of and apparatus for inter-area 
rekeying of encryption keys in secure mobile multicast communications as 
described in the accompanying claims. 

5 Brief description of the drawings 

Figure 1 is a schematic diagram of the architecture of a distributed group key 
management system, showing Traffic Encryption Key distribution 

Figure 2 is a schematic diagram of the group key management system of 
Figure 1 , showing inter-area movement of group members, 

10 Figure 3 is a schematic diagram of the group key management system of 

Figure 1, showing a known rekeying method for inter-area movement of group 
members. 

Figure 4 is a schematic diagram of the group key management system of 
Figure 1, showing another known rekeying method for inter-area movement of 
15 group members, 

Figure 5 is a schematic diagram of the group key management system of 
Figure 1, showing yet anottier known rekeying method for inter-area movement of 
group members, 

Figure 6 is a schematic diagram of a group key management system of the 
20 kind shown Figure 1 and Figure 2 for inter-area movement of group members in 
accordance with one embodiment of the present invention, given by way of 
example, 

Figure 7 is a flow chart of an example of a rekeying process when a member 
joins an area in the system of Figure 6, 

25 Figure 8 is a flow chart of an example of a rekeying process when a member 

leaves an area in the system of Figure 6, 

Figure 9 is a flow chart of an example of a traffic key fonA^arding process in 
the system of Figure 6, and 
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Figure 10 is a flow chart of an example of a traffic key reception process in 
tlie system of Figure 6. 

Detailed description of the orefenrfi rt embodiments 

Embodiments of the present invention shown in the drawings enable a 
reduction in the computational capabilities needed for both the key server and 
area members to support encryption/decryption operations due to membership 
dynamism (group join/leave) and member's frequent mobility, by separating 
member's mobility treatment from group membership dynamism, and by 
amortizing the movement impact over the TEK validity period. In addition 
embodiments of the present Invention provide the following features. 

• Reduced impact of member's mobility on group rekeying: the key 
management system, by separating member's mobility treatment from 
group membership dynamism (group join/leave), facilitates movement of 
mobile members between administrative areas while remaining (from a 
group membership viewpoint) in the group. In addition, when the mobile 
member leaves the group, the rekeying process reacts with a limited 
additional impact on the remaining group members. This residual impact is 
typically due to the accumulated infomiatlon that the leaving mobile 
member got from the different areas it visited. 

• Reduced computational requirements for mobile members: mobile 
members have generally very limited resources (e.g. memory space, and 
computational power). Hence, It is useful to minimize for mobile members 
both the memory space requirements (e.g. number and size of stored keys) 
and computations (those Involving cryptographic algorithms In particular). 

• Trust in Mobile members: the group key management system foresees a 
level of trust to attribute to mobile members because they may move across 
different managed areas, and accumulate Infbmiation about local security 
services of the different areas they visit In particular, for some applications, 
such as military communications, the mobile member must be prevented 
from continuing to hold valid keying material ttiat it got from a specific 
security server when the mobile member is out of the management area of 
that server for more tt^an a given period. 
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More particularly, embodiments of the present invention provide the following 
enhancements: 

• avoiding rekeying the members of the visited area each time a mobile 
member enters it; 

• amortizing the impact of member's movement over the TEK lifetime; 

• providing a conditional self-generation of local keys for mobile members to 
reduce signalling between the local GCKS and its members; 

• saving resource consumption using derived key-based rekeying for mobile 
group members. 

This mechanism enables the impact of member's movement on area 
member rekeying and ttiat of the visited area in particular to be reduced 
significantly. It separates the rekeying of mobile members from membership 
dynamism (group join/leave) without affecting the KEK rekieying process. This is 
achieved by introducing a specific key called Visitor Encryption Key (VEK), which 
is provided to mobile members when they move to a new area. 

In more detail, as shown in Figure 6, when the mobile member MMg moves 
fonn area, to areaj, it sends a signalling message to GCKSi of the area it is leaving 
as well as a signalling message to GCKSj of the area in which it is arriving to notify 
them about its mobility. The signalling messages may be implemented as In 
FEDRP and IR, using credentials, for example as described in S. Griffin. B. 
DeCleene, L. Dondeti, R. Flynn, D. Kiwior. and A. Olbert." Hierarchical Key 
Management for Mobile Multicast Members". Once MMn is in the new areaj, the 
GCKSj sends the Visitor Encryption Key VEI^ rather than the KEKj to the mobile 
member using a secure channel. This key VEK) acts similarly to a KEK within this 
areaj but is not used by members MMj already in the area| and possessing the 
current KEKj. 

There are two types of owner lists for the GCKSs: EKOL (for example similar 
to that described in B. DeCleene, L.Dondeti. S. Griffin, T. Hardjono, D. Kiwior, J. 
Kurose. D. Towsley, S. Vasudevan, and C. Zhang, "Secure Group 
CommunicaBons for Wireless Networks", Proceeding of Military Communications 
Conference, IEEE MILCOM, Communications for Network-Centric Operations: 
Creating the Infonnation Force. X^enna, October 2001, pp. 113-117) and in 



<6Onain6ar20l» 



-12- 



addition a Visitor-Key Owner List 'VKOL* that distinguishes between group 
members MMi situated in the respective group key management areai and group 
members MMg that were situated in the respective group key management areaj 
area,- but are visiting another area areaj. In this embodiment of the present 
invention. Visitor-Key Owner Lists (such as VKOL)) contain the list of members still 
holding a valid VEK (such as VEKO but which have subsequentiy left the key area 
(areai) In which they obtained ttie VEK. It is wittiin the scope of the present 
invention, however, to modify the system to function in other ways, for example so 
that tiie Visitor-Key Owner Lists (such as VKOU) contain the list of members still 
holding a valid VEK (such as VEKi) and which are still in the key area (areai) in 
which they obtained the VEK. This may assume that GCKSi can distinguish 
between members holding VEKi and are out of areaj from those that are in. For 
example, when the VKOLj is reset (as described below) only members with VEKi 
and that are out of areai will be removed. 

The flow charts shown in Figures 7 to 10 show In more detail examples of the 
processes that the local 6CKS perfonms in the embodiment of Figure 6 when a 
new member enters or leaves the area. The processes shown include Group join 
and leave, as well as movement of a current group member between two areas. 

In the embodiment of the invention shown in Figure 6, when a mobile 
member MMy moves intra-group from areai to areaj. ttie following processes will be 
triggered.: 

• if tills mobile member MM^ holds a VEKi, the GCKSi places the member in 
the VKOLi list. 

• if tiie mobile member MMg holds a KEKj, the GCKSi places that member In 
the EKOU list. 

In both cases, the GCKSi triggers a validity period (as in FEDRP) for tiie local 
key VEKi or KEKi tiiat ttie mobile member MMy holds. Subsequently, if the mobile 
member returns to areai during Uie validity period, the GCKSi removes this 
member from ttie list and no local rekeying occurs (optionally, CSCKSi provides tiie 
entering member with the cunrent TEK). Accordingly, it is unnecessary to rekey 
area members when a mobile member returns to a previously visited area. 
However, if the mobile member remains out of the areai and the period expires, 
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the local GCKSj resets the owner list EKOU or VKOU and distributes a new local 
key (KEKi or VEK|) to each concerned local member using a secure channel. 

Once the mobile member MM^ enters the areaj, we may distinguish two 
cases: 

• If there are no VEKj-members, the GCKSj generates a VEKj key (rather 
than a new KEK[) and sends It (optionally, along with the current TEK) to the 
visiting member MMg In a secure channel, and the KEK^ remains 
unchanged. 

• If VEKj-members exist, the GCKSj checks first whether the current VEKj 
was used to encrypt the previous TEK. If it is not the case, the GCKSj will 
provide the entering mobile member MMy the cunrent VEI^. Otherwise, the 
GCKSj will provide the entering mobile member MMg a new VEKj derived 
from the current value of VEKj (preferably using a one-way hash function, 
for instance: VEKNew=Hash(VEKcurreni)). During the validity period of the 
current TEK, the local GCKSj may not derive more than once a new VEKj 
value whatever the number of new mobile members that enter GCKSj's 
areaj during the TEK validity period, since the visited GCKSj is unaware 
when the visiting mobile member MMy joined the group in a different area. 

Note that in all cases, no local rekeying (KEKj or VEI^) is triggered whenever 
a mobile current group menriber MMg moves between two areas. Besides, both 
Backward and Fonvard secrecies are ensured. Hence, this embodiment of the 
present invention separates fully member's Intra-group mobility from group 
membership dynamism (group join/ leave). 

When a new member (as opposed to a current group member entering the 
area by intra-group mobility) joins the group via a given areat where there are 
VEK-members, the local GCKSj will distribute a new KEKi to all the area members 
encrypted separately with the current KEKi and the cunrent VEKi. As a result, all 
the cunrent area members will then hold the new KEKi. The KEKj is distributed by 
unicast to the new member as well using a secure channel. Next, the Domain 
GCKS multicasts securely the new TEK to all the area GCKSs. Each area GCKS 
then multicasts the new TEK to all the group members using the local area keys 
(local KEKs, and local VEKs when and where there are VEK-members). 
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When any group member leaves the multicast group (as opposed to a 
current area member leaving the area by intra-group mobility), all the area keys it 
holds are changed within the affected areas. In this way, for a given areas, the 
GCKSi sends either a new KEKi or a new VEKi (depending on which local key the 
5 leaving member holds) to the concerned members of the areai using a secure 
channel with each member, which may be any secure channel except that based 
on current VEK/KEK, for example a unicast channel. Next, the Domain GCKS 
multicasts securely the new TEK to all the area GCKSs. Each area GCKS then 
multicasts the new TEK to all the group members using the local area keys (local 
10 KEKs, and local VEKs when and where there are VEK-members) In 
circumstances where it Is desired for a mobile member to be able to change 
multicast address while keeping the same Traffic Encryption Key TEK, it is 
unnecessary to send the mobile member a new TEK or to rekey the TEK. 

If the rekey Is a KEKi rekey, all the local members will be sent the new KEKi 
15 and the local VKOL list is reset (previous members who visited the areaj are 
absent will no longer hold a valid VEKi); in this case, any group members still in 
the areai that hold a VEK] will switch to the new KEKi. Once in place, the local 
GCKSi distributes the new TEK in one multicast transmission using the local keys. 

However there is no need to change the KEK|S of the aresi if the leaving 
20 member held only the VEK|. Hence, we save resource consumption since the local 
KEKi remains unchanged. In fact, in prior art approaches, when a member leaves 
the group session, a new local KEK is distributed individually for each remaining 
area member before a new TEK is multicast to these members. For some 
applications, the multicast traffic is intemjpted until the new TEK will be distributed. 
25 This may Increase session interruption latency particularly when the number of 
remaining area members is important. With this embodiment of the present 
invention, when the member leaving areai holds a VEKi and not a KEKi, the 
session interruption latency is significantly reduced whether or not the number of 
KEKi-members in the affected areai is significant. Such a gain of processing time is 
30 particularly valuable in real-time applications. 
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For both group join and leave cases, the EKOLi as well as the VKOLi lists on 
which the leaving member is listed are reset when the new local key Is distributed 
to areai members. 

In summary, in this embodiment of the present invention, the VEKi can be 
considered as a temporary key. since the members holding such a key in a given 
area will switch to the new KEK| when a KEK, rekeying occurs (atter a group join or 
periodic rekeying). Any additional processing that management of the VEKi may 
introduce In the GCKSi Is negligible. 

It Is within the scope of the present invention, however, to modify the system 
to function in other ways with respect to VEK management, for example, so that a 
new member receives an updated VEK rather than an updated KEK. Another 
modification would suggest that when a member holding a VEKi leaves the group, 
the GCKSi may distribute a new KEK| (rather than updating VEKi as described in 
our basic mechanism) for all the remaining areat members using a secure channel 
with each of those members. 

Each time the local GCKSi needs to fonward a new TEK (TEK rekey) within 
its areai that includes VEKi-members. it multlcasts the new TEK separately 
encrypted with KEKi and VEKi. To achieve this, the local GCKSj checks first if it 
has obtained the current VEKi by derivation from the previous one since the 
previous TEK fonA^arding. 

If so, the local GCKSi notifies the VEKi-members (within the TEK distribution 
message) that the new TEK they are receiving is encrypted with a new VEKi 
(derived finom the previous one see above). The VEKi-members then decrypt this 
new TEK using the derived VEKi (the members obtain the new VEKi by applying 
the same function to the previous VEK| as the one that was applied by the GCKSj 
server). 

If no derived VEKi value has been generated since the previous TEK 
fonvarding, it means that the VEKi has not been changed since then. Thus, the 
GCKSj encrypts the TEKj with the current value of the VEKi and multicast it to 
VEKi-members, notifying them not to obtain a derived VEKi. 
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Ciaims 

1. A method of inter-area rekeying of encryption keys in secure mobile multicast 
communications, in which a Domain Group Controller Key Server (Domain 
GCKS) distributes Traffic Encryption Keys (TEK) to a plurality of local Group 
Controller Key Servers (local GCKS) serving respective group key 
management areas, and sakJ local Group Controller Key Sen/ere forwarel said 
Traffic Encryption Keys, encrypted using Key Encryption Keys (KEK,, KEK,) 
that are specific to the respective local Group Controller Key Server (local 
GCKSi, GCKSj), to group members situated In the respective group key 
management areas, said local Group Controller Key Servers (GCKS{. GCKSi) 
constituting Extra Key Owner Lists (EKOU. EKOL4) for said group key 
management areas (areai, areaj) that distinguish group members (MM,, MMj) 
possessing Key Encryption Keys (KEKi. KEI^) and situated in the 
corresponding group key management area (areai. areaj) from group members 
(MMij) possessing Key Encryption Keys (KEKi) that were situated in the 
conresponding group key management area (areai) but are visiting another 
area (areaj), 

characterised In that said local Group Controller Key Servers fonA^ard said 
Traffic Encryption Keys (TEK) to group members (MMij) visiting the respective 
group key management areas (areaj) encrypted using a Visitor Encryption Key 
(VEI^) that is specific to the respective local Group Controller Key Server 
(GCKSj) and Is different from said Key Encryption Key (KEKj). 

2. A method as claimed in claim 1, and comprising rekeying said Traffic 
Encryption Keys (TEK) after rekeying said Key Encryption Key (KEKi. KEI^). 

3. A method as claimed in claim 1 or 2, wherein said local Group Controller Key 
Servers (GCKS,, GCKSj) rekey a Key Encryption Key (KEK, KEI^) by a 
process including sending a new Key Encryption Key (KEKi. KEKj) to cun-ent 
group members encrypted using the cun-ent Key Encryption Key (KEKi. KEKj) 
and to visiting group members using the Visitor Encryption Key (VEKi, VEKj). 
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4. A method as claimed in claim 1 or 2, wherein said local Group Controller Key 
Server GCKSi sends the Visitor Encryption Key (VEKi) rather than the Key 
Encryption Key (KEKi) to new members joining the group via areai. 

5. A method as claimed in claim 3. wherein said local Group Controller Key 
Servers (GCKSi, GCKSj) rekey a Key Encryption Key (KEKi, KEKj) by a 
process Including sending said new Key Encryption Key (KEKj, KEKj) 
selectively to existing group members situated in the corresponding group key 
management area (areai, areaj). 

6. A method as claimed in claim 3 or 5, wherein said local Group Controller Key 
Servers (GCKSi. GCKSj) rekey a Key Encryption Key (KEKj, KEI^) by a 
process Including sending a new Key Encryption Key (KEKi, KEKj) to existing 
group members using multicast messages and to visiting group members over 
a different secure channel. 

7. A method as claimed in claim 6, wherein said Key Encryption Key (KEKi, KEKj) 
Is sent to visiting group members over said different secure channel using a 
unicast message. 

8. A method as claimed In any of claims 3 to 7, wherein rekeying a Key 
Encryption Key (KEKi, KEKj) comprises said local Group Controller Key 
Servers (GCKSi, GCKSj) sending a new Key Encryption Key (KEKi, KEI^) 
selectively to current group members currently situated in the corresponding 
group key management areas (areai. areaj). 

9. A method as claimed In any preceding claim, wherein said local Group 
Controller Key Servers (GCKSi, GCKSj) rekey said Visitor Encryption Keys 
(VEKi, VEI^) by a process including sending a new Key Encryption Key (KEKi, 
KEKj) to said visiting group members using tiie Visitor Encryption Key (VEKi, 
VEI^). 

10. A method as claimed in any preceding claim and Including said local Group 
Contixjiler Key Servers (GCKSj, GCKSj) constituting Visitor Key Owner Lists 
(VKOU, VKOLj) for said group key management areas (areai. areaj) tiiat 
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distinguish group members (MM,, MMj) possessing Visitor Encryption Keys 
(VEKi, VEK,) and situated in the con-esponding group Icey management area 
(area,, areaj) from group members (MMq) possessing Visitor Encryption Keys 
(VEKi) that were situated In the conresponding group Icey management area 
(area,) but are visiting another area (areaj). 

11. A method as claimed in claim 10 wherein said Extra Key Owner Lists (EKOLi, 
EKOLj) and said Visitor Key Owner Lists (VKOL,. VKOLj) comprise lists of the 
group members (MMq) possessing Key Encryption Keys (KEK,), respectively 
Visitor Encryption Keys (VEK,. VEi^). that were situated in the corresponding 
group key management area (area,) but are visiting another area (area,). 

12. A method as claimed in any preceding claim, wherein a group member (MM,,) 
that was visiting another group key management area (area,) returns to an 
area (area,) for which It possesses a corresponding Key Encryption Key (KEK,) 
or Visitor Encryption Key (VEK,) before expiry of a validity period set by the 
conresponding Group Conbroller Key Sender (GCKS,) without said 
corresponding Group Continolier Key Server (GCKS,) rekeying said Key 
Encryption Key (KEK,). 

13. A method as claimed In any preceding claim, and including said local Group 
Confroller Key Server (GCKS,) sending a new Visitor Encryption Key (VEI^) to 
a visiting group member (MMg) amving In the con-esponding group key 
management area (areaj) If there is no other visiting group member (MMg) 
situated in the con-esponding group key management area (areaj). and If a 
current Visitor Encryption Key (VEKj) exists that has already been used to 
encrypt a previous Traffic Encryption Key (TEK). 

14. A method as claimed In claim 13. wherein sending a new Visitor Encryption 
Key (VEKj) to a visiting group member (MM,j) arriving In the corresponding 
group key management area (areaj) comprises deriving the new Visitor 
Encryption Key (VEK,) from the current Visitor Encryption Key (VEi^) using a 
secure function known to cun-ent visiting group members (MMg). and 
foHA^arding said Traffic Encryption Keys (TEK) subsequently to group members 
(MMij) visiting the respective group key management areas (aiea,) includes 
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indicating whether said Traffic Encryption Keys (TEK) is encrypted using such 
a derived Visitor Encryption Key (VEKj). 

15. A method as claimed in claim 13, wherein said secure function for deriving the 
new Visitor Encryption Key (VEI^) comprises a one-way hash function. 

16. A method as claimed in any preceding claim, wherein said local Group 
Controller Key Servers (GCKSi, GCKSj) selectively rekey said Key Encryption 
Key (KEKi. KEKj) and said Visitor Encryption Keys (VEKi. VEK^) when a cunrent 
group member (MM|, MMj, MMij) leaves the group In areas for which the 
leaving group member holds a current Key Encryption Key (KEKi, KEKj), 
respectively Visitor Encryption Keys (VEK|, VEK|). 
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Title : Rekeying in Secure Mobile Multicast Communications 
Abstract 

A method of inter-area rekeying of encryption keys in secure mobile multicast 
communications, in which a Domain Group Controller Key Server (Domain GCKS) 
distributes Traffic Encryption Keys (TEK) to local Group Controller Key Servers 
(local GCKS) serving respective group key management areas. The local Group 
Controller Key Servers forward the Traffic Encryption Keys, encrypted using Key 
Encryptk>n Keys (KEKi, KEI^) that are specific to the respective local Group 
Controller Key Server (local GCKSi. GCKSj), to group members situated In the 
respective group key management areas. The local Group Controller Key Servers 
(GCKSi, GCKSj) constitute Extra Key Owner Lists (EKOLi, EKOLj) for the group 
key management areas (areai, areaj). The EKOLi list tracks group members (MMg) 
possessing Key Encryption Keys (KEKi) that were situated in the corresponding 
group key management area (areai) but are visiting another area (areaj), The local 
Group Controller Key Servers fonward the Traffic Encryption Keys (TEK) to group 
members (MMy) visiting the respective group key management areas (areaj) 
encrypted using a Visitor Encryption Key (VEKj) that is specific to the respective 
local Group Controller Key Server (GCKSj) and Is different from the Key 
Encryption Key (KEI^). The local Group Controller Key Servers (GCKSi. GCKSj) 
also constitute Visitor Key Owner Lists (VKOU, VKOLj). The VKOLi list tracks 
group members (MMg) possessing Visitor Encryption Keys (VEKi) that were 
situated in the corresponding group key management area (areai) but are visiting 
another area (areaj). 
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